Applied-Upstream: 3de96da6cd66b1af7224561c568bc3de50cd1398
Last-Update: 2025-08-18 Reviewed-By: Étienne Mollier <emollier@debian.org>
Fixed an issue with recently committed changes that fix a problem with
invalid YBR_FULL images
Fixed an issue when processing an invalid DICOM image with a Photometric
Interpretation of "YBR_FULL" and a Planar Configuration of "1" where
the number of pixels stored does not match the expected number of pixels
(much too less). Now, the pixel data of such an image is not processed
at all, but an empty image (black pixels) is created instead. The user
is warned about this by an appropriate log message.
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
In this case, only a single pixel is processed, but the pixel matrix is
much larger. Filling the rest of the pixel matrix with the smallest
possible value for the image is not working because of an optimized
memory usage (value would be out of range). Now, the pixel value to be
used is double-checked before it is actually filled into the "background"
of the image.
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Fixed issue when processing an invalid DICOM image where the number of
pixels stored does not match the expected number of pixels (too less)
and the combination of BitsAllocated and BitsStored is really unusual
(e.g. 1 bit stored, but 52 bits allocated). In cases where the last
pixel (e.g. a single bit) does not fit into the buffer of the input
pixel data, a buffer overflow occurred on the heap. Now, the last entry
of the buffer is filled with the smallest possible value (e.g. 0 in case
of unsigned data).
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Added check to the image preprocessing to make sure that the value of
HighBit is always less than the value of BitsAllocated. Before, this
missing check could lead to memory corruption if an invalid combination
of values was retrieved from a malformed DICOM dataset.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the report, sample file (PoC)
and detailed analysis. See TALOS-2024-2121 and CVE-2024-52333.
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
If the stored number is less than the expected number, the rest of the
pixel matrix for the intermediate representation was always filled with
the value 0. Under certain, very rare conditions, this could result in
memory problems reported by an Address Sanitizer (ASAN). Now, the rest
of the matrix is filled with the smallest possible value for the image.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the original report, the sample
file (PoC) and further details. See TALOS-2024-2122 and CVE-2024-47796.
CMake exports are used by other packages that compile
and link against dcmtk. Because Debian moves some of
these executables and also dosn't install the test
executables, this import may fail leading to failure
to configure the according package.
===================================================================
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
In this case, only a single pixel is processed, but the pixel matrix is
much larger. Filling the rest of the pixel matrix with the smallest
possible value for the image is not working because of an optimized
memory usage (value would be out of range). Now, the pixel value to be
used is double-checked before it is actually filled into the "background"
of the image.
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Fixed issue when processing an invalid DICOM image where the number of
pixels stored does not match the expected number of pixels (too less)
and the combination of BitsAllocated and BitsStored is really unusual
(e.g. 1 bit stored, but 52 bits allocated). In cases where the last
pixel (e.g. a single bit) does not fit into the buffer of the input
pixel data, a buffer overflow occurred on the heap. Now, the last entry
of the buffer is filled with the smallest possible value (e.g. 0 in case
of unsigned data).
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Added check to the image preprocessing to make sure that the value of
HighBit is always less than the value of BitsAllocated. Before, this
missing check could lead to memory corruption if an invalid combination
of values was retrieved from a malformed DICOM dataset.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the report, sample file (PoC)
and detailed analysis. See TALOS-2024-2121 and CVE-2024-52333.
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
If the stored number is less than the expected number, the rest of the
pixel matrix for the intermediate representation was always filled with
the value 0. Under certain, very rare conditions, this could result in
memory problems reported by an Address Sanitizer (ASAN). Now, the rest
of the matrix is filled with the smallest possible value for the image.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the original report, the sample
file (PoC) and further details. See TALOS-2024-2122 and CVE-2024-47796.
CMake exports are used by other packages that compile
and link against dcmtk. Because Debian moves some of
these executables and also dosn't install the test
executables, this import may fail leading to failure
to configure the according package.
===================================================================
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
In this case, only a single pixel is processed, but the pixel matrix is
much larger. Filling the rest of the pixel matrix with the smallest
possible value for the image is not working because of an optimized
memory usage (value would be out of range). Now, the pixel value to be
used is double-checked before it is actually filled into the "background"
of the image.
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Fixed issue when processing an invalid DICOM image where the number of
pixels stored does not match the expected number of pixels (too less)
and the combination of BitsAllocated and BitsStored is really unusual
(e.g. 1 bit stored, but 52 bits allocated). In cases where the last
pixel (e.g. a single bit) does not fit into the buffer of the input
pixel data, a buffer overflow occurred on the heap. Now, the last entry
of the buffer is filled with the smallest possible value (e.g. 0 in case
of unsigned data).
Thanks to Ding zhengzheng <xiaozheng.ding399@gmail.com> for the report
and the sample file (PoC).
Added check to the image preprocessing to make sure that the value of
HighBit is always less than the value of BitsAllocated. Before, this
missing check could lead to memory corruption if an invalid combination
of values was retrieved from a malformed DICOM dataset.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the report, sample file (PoC)
and detailed analysis. See TALOS-2024-2121 and CVE-2024-52333.
Fixed issue when rendering an invalid monochrome DICOM image where the
number of pixels stored does not match the expected number of pixels.
If the stored number is less than the expected number, the rest of the
pixel matrix for the intermediate representation was always filled with
the value 0. Under certain, very rare conditions, this could result in
memory problems reported by an Address Sanitizer (ASAN). Now, the rest
of the matrix is filled with the smallest possible value for the image.
Thanks to Emmanuel Tacheau from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the original report, the sample
file (PoC) and further details. See TALOS-2024-2122 and CVE-2024-47796.
CMake exports are used by other packages that compile
and link against dcmtk. Because Debian moves some of
these executables and also dosn't install the test
executables, this import may fail leading to failure
to configure the according package.
===================================================================
CMake exports are used by other packages that compile
and link against dcmtk. Because Debian moves some of
these executables and also dosn't install the test
executables, this import may fail leading to failure
to configure the according package.
===================================================================
Marco Eichelberg [Wed, 13 Mar 2024 16:15:58 +0000 (17:15 +0100)]
[PATCH] Fixed two segmentation faults.
Fixed two segmentations faults that could occur while processing an
invalid incoming DIMSE message due to insufficient error handling
causing a de-referenced NULL pointer.
Thanks to Nils Bars <nils.bars@rub.de> for the bug report and sample files.
This closes DCMTK issue #1114.
Gbp-Pq: Name 0004-Fixed-two-segmentation-faults.patch
Marco Eichelberg [Mon, 15 Apr 2024 10:19:33 +0000 (12:19 +0200)]
[PATCH] Fixed unchecked typecasts and fixed LUT handling.
This commit adds further fixes for unchecked typecasts of DcmItem::search()
results (see description of previous commit). Furthermore, this commit
specifically addresses the handling of look-up tables (LUTs) in module
dcmpstat, where attribute (0028,3006) LUTData may use either US or OW
value representation, and (0028,3002) LUTDescriptor may be either US or SS.
The code should now properly handle all permitted value representations.
LUTData is now always written as OW in order to avoid the 64k size limit
for US in explicit VR encoding.
Thanks to Martin Zeiser from the Cisco Talos team
<vulndiscovery@external.cisco.com> for the bug report (TALOS-2024-1957).
Together with the previous commit, this closes DCMTK issue #1120.
Gbp-Pq: Name 0002-Fixed-unchecked-typecasts-and-fixed-LUT-handling.patch
Marco Eichelberg [Mon, 15 Apr 2024 10:12:51 +0000 (12:12 +0200)]
[PATCH] Fixed unchecked typecasts of DcmItem::search results.
DcmItem::search() returns a stack of DcmObject pointers as search results.
These pointers in most instances need to be casted to DcmItem, DcmElement
or a subclass of these. In many cases, the type of the object was not
properly checked before the typecast. This could lead to segmentation faults
when invalid DICOM datasets were processed where elements had the wrong
value representation.
Gbp-Pq: Name 0001-Fixed-unchecked-typecasts-of-DcmItem-search-results.patch
Joerg Riesmeier [Wed, 8 Nov 2023 10:38:54 +0000 (11:38 +0100)]
[PATCH] Fixed issue with delimiters being converted.
Fixed issue with delimiter character "\" being converted when converting
a DICOM dataset that uses a Specific Character Set of "ISO 2022 IR 13\ISO
2022 IR 87" to UTF-8. The delimiter "\" was incorrectly converted to the
Yen sign when processing the value of an "LO" data element that contains
multiple values but does not use any escape sequences. This issues has
been fixed now by always treating the delimiters in a special way.
Thanks to Mathieu Malaterre <mathieu.malaterre@gmail.com> for the report
and David Gobbi <david.gobbi@gmail.com> for the analysis and testing.
CMake exports are used by other packages that compile
and link against dcmtk. Because Debian moves some of
these executables and also dosn't install the test
executables, this import may fail leading to failure
to configure the according package.
===================================================================
projects / dcmtk.git / log